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Abstract of EP 0854607 (A1) 

The method involves planning the configuration of a 
network (N), whose network elements (NE1,..) are 
configured via an interface, using a database (MIB) 
in which are stored configurations planned for 
different operating times. These are used to set the 
operating parameters of the network elements 
according to the plan. For each plan configuration 
the network elements are stored as objects with their 
parameter settings in an object tree whose data are 
called from the database at the required time and 
fed to the network via the interface (QS). The data 
are used to set up the required configuration 
corresponding to the plan configuration. 




FIG I 



Data supplied from the espacenet database — Worldwide 



http://v3 .espacenet.com/publicationDetails/biblio?DB=EPODOC&adjacent=trae&locale. . . 1 2/1 4/20 1 0 



(19) 



J 



) Veroffentiichungstag: 
22.07.1998 



(21) Anmeldenummer: 98100787.5 

(22) Anmeldetag: 19.01.1998 



~™ IIIIIIIIIIIIIIIIIIIIIIIllIIIIll 

European Patent Office 

Office europeen des brevets (11) EP 0 854 607 A1 

EUROPAISCHE PATENTANMELDUNG 

(51) Int el. 6 : H04L 12/24, H04Q 3/00 



(84) Benannte Vertragsstaaten: 


(71) Anmelder: Siemens Schweiz AG 


AT BE CH DE DK ES Fl FR GB GR IE IT LI LU MC 


8047 Zurich (CH) 


NL PT SE 




Benannte Erstreckungsstaaten: 


(72) Erfinder: 


ALLTLVMKROSI 


• Lehmann, Andre 




8046 Zurich (CH) 


(30) Prioritat: 20.01.1997 CH 99/97 


• Otto, Matthias 




8633 Wollhausen (CH) 



< 

o 

CD 

S 



(54) Verfahren zum Planen und Konfigurieren elnes Korr 

(57) Das Verfahren dient zum Planen und Konfigu- 
rieren eines aus Netzwerkelementen (NE1, NE2. .... 
NEk) bestehenden Kommunikationsnetzwerkes (N), 

wobeidie Netzwerkelemente (NE1, NE2 NEk) uber 

eine Schnittstelle (QS) einstellbar sind. In einer Daten- 
bank(MIB) werden ftir verschiedene Betriebszeitpunkte 
geplante Plan-Konfigurationen (PLAN) des Netzwerkes 
(N) gespeichert, mit denen die Betriebsparameter der 

Netzwerkelemente (NE1, NE2 NEk) entsprechend 

der Planung einstellbar sind. Dabei werden fur jede 
Plan-Konfiguration die Netzwerkelemente (NE1, NE2, 
NEk) als Objekte mit den einzustellenden Betriebs- 
parametem in einem Objektbaum erfasst und dessen 
Daten im gewunschten Betriebszeitpunkt aus der 
Datenbank (MIB) abgerufen und uber die Schnittstelle 
(QS) dem Kommunikationsnetzwerk (N) zugefuhrt. So 
wird fur diesen Betriebszeitpunkt im Kommunikations- 
netzwerk (N) eine Konfiguration eingestellt, die der 
gewunschten Soll-Konfiguration (SOLL) entspricht. Fur 
kunftige Einsatze geplante Soll-Konfiguration werden 
gebildet, indem der aktuellen Soll-Konfiguration (SOLL) 
eine oder mehrere Plan-Konfigurationen, die die vorge- 
sehenen Konfigurationsanderungen enthalten, uberla- 
gert werden. Zur vorgangigen UberprQfung von 
geplanten Konfigurationen wird das Ergebnis der Ober- 
lagerung sichtbar gemacht. 



sou. PLAN 



| NEi~| | NE2 | — — — - |~NEk I 



Q. 
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Beschreibung 

Die vorliegeride Erfindung betrifft ein Verfahren nach dem Oberbegriff des Patentanspruchs 1 . 

In modernen Kommunikationsnetzwerken, wie Fernmeldenetzen, gewinnen Funktionen fUr Betrieb und Wartung 
(Operation, Administration and Maintenance OAM) immer mehr an Bedeutung. Wie in P. Bocker „Das diensteintegrie- 
rende digitale Nachrichtennetz" Berlin 1990, Seite 158 ff. beschrieben, befasst sich die CCITT-Empf. Q542 fur OAM 
u.a. mit Bedien- und Verwaltungsaufgaben im Zusammenhang mLtJem Neueinrichten 

Daten eines Kommunikationsnetzwerkes. Konkret stelltsich den Betreibem solcher Netze immer haufigerdie Aufgabe, 
ihr Netz rasch slch andernden Bedurfnissen anzupassen. Solche Anpassungen betreffen z.B. das Bereitstellen zusatz- 
licher Leitungen oderdas Entfernen von Leitungen in bestimmten Leitungsbiindel n bei voraussehbaren Anderungen im 
Verkehrsaufkommen, Oder die Anderung der Priorisierung von Leitungen im Netz. Dabei ist fur den Betreiber von 
besonderer Bedeutung, Planungen fur verschiedene Netzkonfigurationen im voraus erstellen und priifen zu konnen, 
damit er allfallige sich ungiinstig auf den Betrieb des Netzes auswirkende Fehlplanungen rechtzeitig vor der Implemen- 
tierung im Netz feststellen und korrigieren kann. Ferner miissen die verschiedenen Netzplanungen so verwaltet wer- 
den, dass sie bei Bedarf rasch abrufbar sind und in das Netz implementiert werden konnen. 

Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren anzugeben, das in einfacher Weise 
erlaubt, verschieden e Planungen furdiejfenfi guration (Eins t ellen) elnes Kommunikationsnetzwerkes bereit zu ste llen 
und zu verwalten und daTNitzwerF in einem beliebigen Zeitpunkt entsprechend einer bestimmten Planung zu konflgu- 
rieren. ~~ 

Diese Aufgabe wird durch die im kennzeichnenden Teil des Patentanspruchs 1 angegebenen Massnahmen gelost. 
Vorteilhafte Ausgestaltungen der Erfindung sind in weiteren Anspruchen angegeben. 

Das erf indungsgemasse Verfahren bietet folgende Vorteile: 

- Kiinftige Konfigurationen eines Netzes konnen im voraus mit verschiedenen Planungen erstellt und auf ihre Eig- 
nung fur bestimmte Netzverhaltnisse und Verkehrsaufkommen uberpruft werden. 

- Die Planungen konnen unabhangig von der Struktur des Netzwerkes erstellt werden. 

Die Erfindung wird nachfolgend anhand einer Zeichnung beispielsweise naher erlautert. Dabei zeigt : 

Fig. 1 eine prinzipielle Anordnung zur Durchfuhrung des Verfahrens 

Fig. 2 und 3 konkrete Anwendungen des Verfahrens 

Fig. 1 zeigt eine Anordnung, in der die Erfindung angewendet werden kann. Die Anordnung enthalt einen Bedien- 
teil OP, der mit einem Betriebssystem OS verbunden ist, welches mit einer Datenbank MIB (Managed Information 
Base) in Verbindung steht und auf diese zugreifen kann. fiber eine Schnittstelle QS ist das B etriebssystem OS mit 
Netzw erkelementen NE1, NE2, ..■.■■ ^.NEk.eines Kommunikationsnetzwerkes N verbunden . Netzwerkelemente NE sind 
elHitiiibare physikalische Teile~und ElementTeines Kommunikationsnetzwerkes N etc. Solche Elemente konnen 
sowohl Hardware-Elemente (wie Teilnetze, KnotenA/ermittlungsstellen, Leitungsbiindel oder einzelne Leitungen zwi- 
schen den Knoten, Baugruppen, Schnittstellen, Leitungen etc.) als auch Softwareelemente (z.B. geschaltete Verbin- 
dungen) sein. Der Bediente ilfjjf das Betriebssystem S^die Datenbank^pijnd die Schnittstelle ^^bilden 
zusammen ein soaenannteslSmmmmmi^am^Um^^^Ss fur die Steuerung und Einstell ung 

derEle mente NE1, NE2 NEk verantwortlich ist. Die^mmurtiOor^wischen den erwahnten leilen des TMN 

prfnlnfriBmass CCITT-Empfehlung X.71 0 bis X.71 2. Insbesondere ist das Betriebssystem O S fur die Verwaltunq. Ober- 
wachung und Konfiguration der Elemente NE zustandig. JJ nter Kgnfiguratjon soil hier das Einstellen bestimmter 
Befriebszustande von Elementen NE verstanden werden. Dabei we rden die Be }"^^^ ^^L^^^^^^ 
i iarf -idnded Sgi^djnjf gej r t l jer beisj gl weisebeij j1Ttg*eTiena^6riten v^erkenrsaTOTOff 

Fm Netzwerk N notwendig werden, indem fur diese Zeit mehr Leitungen zwischen bestimmten Knoten im Netzwerk N 
eingeschaltet werden miissen. Ferner konnen Anderungen des Signalisierverfahrens oder die Umleitung des Verkehrs 
von einem Leitungsbiindel auf ein anderes zwischen zwei Knoten eines Netzes erforderlich werden. JKonfigurationsan- 
derungen konnen vom Netzbetreiber Ciber den Bedienteil OP eingegeben werden. Das Betriebssystem OS~SDtglrdann~ 
dafur, dass das Netzwerk N entsprechend konf igurieff wird. Als weitere Aufgabe des Betriebssystems OS kann vorge- 
sehen werden, geeignete Massnahmen in einem Element NE einzuleiten, wenn das Betriebssystem OS von diesem 
eine Fehlermeldung erhalt. Die Schnittstelle QS ist eine normierte Schnittstelle (z.B Q3-Adapter gemass CCITT. Rec. 

M.3010), die die zwischen dem Betriebssystem OS und den Elementen NE1 , NE2 NEk ausgetauschten Meldun- 

gen und Daten erforderlichenfalls konvertiert. Als Bedienteil OP kann ein Personalcomputer od er eine Workstation vor- 
gesehen werden, uber die die Befehle fur "das Betriebssystem OS eingegeben werden. Eine Bildschirmanzeige 
ermoglicht dem Betreiber interaktiv mit dem Betriebssystem OS zu kommunizieren. 

FOrjedesvo rn Management Network TMN verwa.ltete Element NE d es Kommunikationsnetzwerkes N ist in der 
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DatenbankMIB ein Objekt (Managed Object gemass CCITT-Rec. M.3010) vorhand en. J gries Ohje kt pnthait Hie Finen- 
sohaftan unH 7nst andi -»Hgs vnn i hm rgprag entierten Elementes. Auch jede Funktion, die das Kommunikationsnetzwerk 
N ansfiihren kann. wird in einem Objekt erfasst. Dabei kann ein Objekt ein oder mehrere Elemente oder Funktionen 
reprasentieren. Umgekehrt kann ein Element oder eine Funktion auch durch mehrere Objekte reprasentiert werden. 

.Ajl e in der Datenbank MIB enthaltenen Objekte stellen zusammen ein InformationsmodelK z.B. gemass Guidelines 
for the Definition of Managed Objects in Abstract Syntax Notation One ASN.1) des zu steuernden Kojpmunikations- 

Mit der Definitiondes Modells wird festgelegt, was dei BVtreBsf des KomWuVtetionsnstzwerkes N uberdas Betriebs- 
system OS im Netzwerk N steuern kann. Die Kommunikation des Betriebssysterns OS mit dem Bedienteil OP, der 
DatenbankMIB und der Schnittstelle QS erfoigt mittels definierter Meldungen (Indications, Notifications, Confirmations 
etc.)- Das Betriebssystem OS kann uber definierte Kommandos (z.B. CMISE-Kommandos gemass CCITT Rec. 
X.700ff, insbesondere X.71 1) I es end und sc hreiben d auf die Objekte in der Dat enba nk MIB zugreifen. 

^P^|^^f<y.-'yK NUB^ ffl ^^^pj^^Qfj g»j_a'ion' SOLL des Netzwerkes N ^ spsael eine oder mehrere fur verschie- 
deneBeTnebszeitpunkte gepla^^^^^^ffl^^Sne^ PLAN des Netzwerkes N |B||§g|j§||||^Sowohl der Soil- als 
auch den Plan-Konfigurationen liegnJaserwahnte Informationsmodell zugrunde. Die Soll-Konfiguration entspricht dem 
Zustand, dem das Netzwerk N im aktuellen Betriebszeitpunkt gemass den Vorgaben des Betreibers tatsachlich ent- 
spr echen muss. 

T^f in der Datenbank MIB'g^pejgj^^g^aQ-K^gujat^^^^Srjfen vein B^ii- b-i des Netzwerkes N uber 
den Bedienteil OP fur einen bestimmten Betriebszeitpunkt eing^Senel^^^^^^riBeAiig^^Sie konnen vom 
Betreiber abgerufen und zur Erzeugung von neuen (kunftigen) Soll-Konfigurationen verw endet werden, welche spater 
in einem gewunschten Zeitpunkt im Netzwerk N implementiert werden konnen. Dabei entsteht - wle Welter unten noch 
beschrieben ist - eine neue Soll-Konfiguration durch Uberlagerung einer bestehenden (alteren) Soll-Konfiguration mit 
einer oder mehreren Plan-Konfigurationen. Eine derart erzeugte neue Soll-Konfiguration kann dann vor der Implemen- 
tierung in das Netzwerk N dem Betreiber z.B. uber einen Bildschirm sichtbar gemacht werden. Dies ermoglicht dem 
Betreiber, beliebige Planungsversuche durchzufuhren. Ferner kann er Fehlplanungen rechtzeitjg vor der Implementie- 
rung feststellen und zu korrigieren. 

Nach der erfolgreichen Implementierung einer Plan-Konfiguration im Netzwerk N wird diese Plan-Konfiguration in 
die' Datenbank MIB uberfuhrt. Dabei wird die in der Datenbank MIB enthaltene Soll-Konfiguration entsprechend aktua- 
lisiert, indem die Daten der Plan-Konfiguration in die Soll-Konfiguration geschrieben werden. Damit entspricht die Soll- 
Konfiguration in der Datenbank MIB dem tatsachli chen Zus tand der Netzwerkelemente im Netzwerk N. 

Es kann auch vorgesehen werden, dass die^^^^gjration if . i Uatenbart^MJE Ib'sfl g n Muswartffi^j 



prozedur auslost, aufgrund der das Betriebssystem OS alle oder nur einen feil der relevanten Daten in den 
Netzwerkelementen NE1, NE2, ... NEkabfragt und mit den Soll-Da ten in der Datenbank MIB vergleicht und die Soll- 
Konfiguration in der Datenbank MIB soweit erfarderl i ch aktuaiisiert. " ~~ 



entsprechende Konfigurationsanderung vdr'genommen wird. Aucn nierzu weraen GMISE-Kommandos verwendet. 
Dabei kann vorgesehen werden, dass alle Operationen, die der Bediener am Bedienteil OP eingibt, zunachst vom 
Betriebessystem OS i m Informationsmodell auf Zulassigkeit gepruft u nd vom Betriebssystem OS nur dann an das 
Netzwerk N weitergegeben werden, wenn die Operation gultig ist. ~ 

Anhand von Fig. 2 wird nachfolgend ein konkretes Anwendungsbeispiel der Erfindung beschrieben. Dabei wird 
angenommen, zwei Knoten (Vermittlungsstellen) A und B eines Kommunikationsnetzwerkes N seien momentan durch 
drei Verbindungsleitungen miteinander verbunden. Diese aktuelle Konfiguration des Netzwerkes N soil nun geandert 
werden. Dabei wird die Anzahl Verbindungsleitungen zwischen den Knoten A und B von drei auf zwei reduziert, indem 
die Leitung 2 ausgeschaltet wird. 

In Fig. 2a ist die aktuelle Soll-Konfiguration „Soll" des Netzwerkes N als Ausgangszustand mit zwei Knoten und mit 
drei Verbindungsleitungen in einem Objektbaum dargestellt. Im Baum enthalten die Knoten A und B je drei Leitungen 
1,2 und 3, die mit ihren Endpunkten im jeweils anderen Knoten gekennzeichnet sind, d.h. auf den zugehorigen Lei- 
tungsendpunkt im anderen Knoten referenzieren. Fur den Knoten A sind dies die Leitungsendpunkte NB1, NB2 und 
NB3, fur den Knoten B die Endpunkte NA1 , NA2 und NA3. 

In Fig. 2b ist der Objektbaum einer fur einen bestimmten Einsatzzeitpunkt geplanten Konfigurationsanderung 
(Plan-Konfiguration „Plan n") des Netzwerkes N mit nur noch zwei Verbindungsleitungen zwischen den Knoten A und 
B gezeigt. Die Plan-Konfiguration baut auf der gleichen Objektbaum-Struktur auf wie die Soll-Konfiguration in Fig.2a 
auf. Gemass Plan-Konfiguration „Plan n" weist der Baum die unveranderten Objekte Netzwerk N, Knoten A und B 





Betriebssyste 
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sowie die zu loschenden Objekte NA2 (Endpunkt der Leitung 2 im Knoten A) und NB2 (Endpunkt der Leitung 2 im Kno- 
ten B) auf. Die zu loschenden Objekte NA2 und NB2, welche die zu eliminierende Leitung 2 reprasentieren, sind in Fig. 
2b mit „x" gekennzeichnet. Im gewunschten Zeitpunkt konnen die Daten der Plan-Konfiguration „Plan n" mit dem 
CMISE-Kommando ..Action Download" iiber das Bedienteil OP vom Betriebssystem OS in das Netzwerk N iiberfuhrt 
(implementiert) werden, worauf dort die Einstellungen der betreffenden Netzwerkelemente NE entsprechend geandert 
werden. Nachher wird in der Datenbank MIB die Soll-Konfiguration von Fig. 2a mit den Daten der Plan-Konfiguration 
von Fig. 2b iiberschrieben. Daraus resultiert neue Soll-Konfiguration gemass Fig. 2c, in der gemass Planung die Lei- 
tung 2 zwischen den Knoten A und B als nicht mehr existiert, entspricht dann dem neuen aktuellen Zustand des Netz- 
werkes N. Die verwendete Plan-Konfiguration „Plan n" kann in der Datenbank MIB aufbewahrt und fur eine spatere 
Planung zur Verfugung gehalten werden. Die neue Soll-Konfiguration „Soll" bleibt im Netzwerk N wirksam, bis sie durch 
Implementierung einer neuen Plan-Konfiguration verandert wird. 

Fur den Betreiber eines Kommunikationsnetzwerkes kann es nun sehr nutzlich und im Hinblick auf kunftige Anfor- 
derungen an das Netzwerk hilfreich sein, wenn er vorsorglich verschiedene Planungen durchftihren und testen kann, 
bevor er deren Ergebnis in das Netzwerk implementiert. So kann er insbesondere auch allfallige Fehlplanungen fest- 
stellen und rechtzeitig korrigieren, bevor sie sich im Netzwerk ungiinstig auswirken. Hierzu wird vorgesehen, aus der 
Planung resultierende neue geplante Soll-Konfigurationen dem Betreiber des Netzwerkes N sichtbar zu machen und 
beispielsweise auf einem Bildschirm darzustellen. Im folgenden wird eine solche neue vorerst nur geplante Soll-Konfi- 
guration im Gegensatz zu einer tatsachlich im Netzwerk N bereits implementierten Soll-Konfiguration „Soll" als 
'geplante Soll-Konfiguration „Soll:Plan n"' bezeichnet. Eine geplante Konfiguration „Soll:Plan n" ist also eine aus einer 
bestimmten Planung resultierende, jedoch noch nicht im Netzwerk N implementierte neue Soll-Konfiguration: Eine 
geplante Soll-Konfiguration „Soll:Plan n" wird erzeugt, indem eine Plan-Konfiguration „Plan n" in nachfolgend beschrie- 
bener Weise der aktuellen Soll-Konfiguration „Soll" uberlagert wird. 

Die Namensgebung (Naming) der einzelnen Objekte im genannten Informationsmodell erfolgt gemass CCITT-Rec. 
X.720 (insbesondere Kap. 6 ..Principles of containement and naming"). Die zur vollstandigen IdenMikation eines Objek- 
tes erforderliche Adresse besteht aus einem Distinguished Name (DN), der aus einer Sequenz von Relative Distinguis- 
hed Names (RDN) aufgebaut ist. So kann der DN fur die Leitung 2 im Knoten A des Netzwerkes N mit der Sequenz 

[ [Netzwerk-ldentifikation:N] [Knoten-ldenfrfikation:A] [Leitungs-ldentifikation:2] ] 
dargestellt werden. Der Einfachheit halber wird im folgenden eine Schreibweise verwendet, in der die in den massge- 
benden CCITT-Rec. vorgesehene Attribut-ldentifikation der einzelnen RDN weggelassen ist. Der DN fur die Leitung 2 
lautet dann vereinfacht 
[[N][A][2]]. 

Der DN fur die Leitung 2 besteht also aus den drei RDN [N], [A] und [2], wobei N der Wert des Attributs ..Netzwerk" (z.B. 
ein Teilnetz innerhalb eines Kommunikationsnetzes), A der Wert des Attributs ..Knoten" (Knoten A im Teilnetz) und 2 der 
Wert des Attributs ..Leitung" (am Knoten A angeschlossene Leitung 2) ist. Selbstverstandlich kann dieser DN mit wei- 
teren RDN erganzt werden, wenn dies zur eindeutigen Adressierung bzw. Identifizierung der Leitung 2 in einem 
umfangreichen Kommunikationsnetzwerk erforderlich ist. 

Im Rahmen der vorliegenden Erfindung wird nun im DN eines jeden Objektes ein weiterer RDN eingefuhrt, der zur 
Identifikation, d.h. zur Unterscheidung der Konfigurationsart (Soll-oder Plan-Konfiguration) dient und dessen Attribut- 
wert zur Erzeugung einer geplanten Soll-Konfiguration speziell verwendet wird. Dabei wird im Naming fur ein Objekt in 
der Soll-Konfiguration ein RDN mit dem Attributwert „Soll", im Naming fur ein Objekt einer Plan-Konfiguration ein RDN 
mit dem Attributwert „Plan n" und im Naming der aus einer Planung hervorgehenden geplanten Soll-Konfiguration ein 
RDN mit dem Attributwert „Soll:Plan n" eingefuhrt. Darin ist „n" eine Nummer zur Unterscheidung von verschiedenen 
fur bestimmte Betriebszeitpunkte des Netzwerkes N vorgesehenen Planungen. Fur die Adressierung der Leitung 2 im 
Knoten A des Netzwerkes N ergibt sich dann in der Soil-Konfiguration der DN 

[ [Soli] [N] [A] [2] ] 
und in der Plan-Konfiguration der DN 

[[Plann][N] [A] [2] ]. 

Die verschiedenen Attribut-Werte „Sdll" und „Plan" im ersten RDN des DN eines Objektes legen somit fest, ob das 
angesprochene Objekt zu einer Soil- oder einer Plan-Konfiguration gehort. 

Die spezielle Adressierung wird nun auf die Objekte von Fig. 2 angewendet. Die in Fig. 2a dargestellte Soll-Konfi- 
guration „Soll" enthalt im zugehorigen Objektbaum 9 Objekte mit folgenden Adressen: 
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Nelzwerk N 
Knoten A 

Endpunkt Leitung 1 
Endpunkt Leitung 2 
Endpunkt Leitung 3 

' B 

1 
2 
3 



[ [Soil] IN] ] 
[ [Soil] [N] [A] ] 
[ [Soil] [N] [A] [1] ] 
[ [Soil] [N] [A] [2] ] 
[ [Soli] [N] [A] [3] ] 
[ [Soil] [N] [B] ] 
[ [Soil) [N] [B] [1] ] 
[ [Soil] [N] [B] [2] ] 
[[Soil] [N] IB] [3]} 



Die in Fig. 2b dargestellte Plan-Konfiguration ..Plan n" enthalt im zugehorigen Objektbaum 
Naming analog wie oben wie folgt gewahlt wird: 

N [ [Plan n] [N]] 

A f [Plan n] [N] [A] ] 

2 . [ [Plan n] [N] [A] [2] ] .Remove" 

B [[Plann][N][B]] 

2 I [Plan n] [N] [B] [2] ] .Remove" 



Die zwei die Endpunkte der Leitung 2 reprasentierenden Objekte, die gemass Planung zu eliminieren ist, enthalten 
zusatzlich ein Attribut ..Intention" mit dem Wert ..Remove", welches die Elimination der Leitung 2 bewirkt. Als weitere 
as Werte des Attributes ..Intention" konnen ..Modify", ..Create" und ..Hold" vorgesehen werden, urn entsprechende Planun- 
gen durchfuhren zu konnen. 

Eine neue geplante Soll-Konfiguration „Soll:Plan n" wie durch Oberlagern der bestehenden Soll-Konfiguration 
„Soll" mit einer Plat-Konfiguration ..Plan n" erzeugt. Zur Obertagerung werden samtliche im Informationsmodell enthal- 
tenen Objekte nacheinander angesprochen, wobei zur Abfrage der Befehl ( get > verwendet wird. Bei der Adressierung 

40 eines abzufragenden Objektes werden mehrere Werte des Attributs ..Konfiguration" eines RDN - voneinander durch 
einen Doppelpunkt getrennt - angegeben, wie z.B. <get „Soll:Plan n") . Dadurch werden verschiedene Objektadressen 
definiert, was bedeutet, dass das Attribut an dieser Stelle einen der angegebenen Werte haben kann. In dem in Fig. 2 
dargestellten Fall wird beispielsweise das Objekt NB2 mit der Abfrage (get [ [SollPlan n] [N] [B] [2]> angesprochen, 
was bedeutet, dass das Objekt mit der Adresse [ [Soli] [N] [B] [2] ] und das Objekt mit der Adresse [ [Plan n] [N] [B] [2] 

45 ] angesprochen werden. Die diese Abfrage durchfuhrende Prozedur der Datenbank MIB sucht nun zunachst in der 
Datenbank MIB nach der in der Abfrage < get [ [SollPlan n] [N] [B] [2] ] > enthaltenen le t zten Obje ktadresse, in diesem 
Fall der zweiten Obiektadresse „[Plan n] [N] [B] [2]", un dstellt te st, dass in der Plan-KonfiquratiorTpian n" em entspre- 
ch end gekennzeichnetes Objekt existiert. Durch den Wert „Hemove" des Attributsjntention" kann das Betriebssystem 
OS feststellen, dass dieses Objekt zu eliminieren ist, was beim Auswerten und Anzeigen des Ergebnisses der Oberla- 

so gerung entsprechend berucksichtigt wird. In der Anzeige wird dieses Objekt dann in einer bestimmten anderen Farbe 
Oder sonstwie als ..eliminiert" gekennzeichnet. 
I Bei der Abfrage des Objektes NA1 mit (get [ [SollPlan n] [N] [A] [1] 1 > wird hingegen keine korrespondierende 
I Objektadresse [ [Plan] [N] [A] [1] gefunden. Deshalb sucht die Abfrageprozedur in der Soll-Konfiguration „Soll" nach der 
j zweitletzten in der Abfrage formulierten Objektadresse, in diesem Fall der ersten Objektadresse mit dem Attribut ..Soil". 

55 Sie f indet diese in [ [Soil] [N] [A] [1 ] ] und erklart diese Adresse demzufolge als gultig. Die Abfrageprozedur sucht also 
aufgrund der Abfrage (wie z.B. (get [ [SollPlan n] [N] [A] [1] ] >) aufeinanderfolgend von „rechts nach links" in den 
betreffenden Konfigurationen (Plan- bzw. Soll-Konfiguration) nach einer gultigen Objektadresse, d.h. nach einer 
Adresse, zu der in den Konfigurationen tatsachlich auch ein Objekt existiert. Wenn dabei keine gultige Adresse gefun- 
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den wird, erfolgt uber das Betriebssystem OS eine entsprechende Ruckmeldung zum Bedienteil OP gemass CCITT 
X.71 Iff. In gleicher Weise wird mit alien Objekten (NA, NA1 ... , NB, NB1 ... ) des Objektbaums verfahren. 

Somit entsteht durch die Oberlagerung der Soll-Konfiguralion „Soll" (Fig.2a) mit der Plan-Konfiguration „Plan n" 
(Fig.2b) in der beschriebenen Weise die folgende geplante Soll-Kbnfiguration „Soll:Plan n": ■ 





[ [SolhPli 


in n] [N] ] 


-> 


[ [Plan n] [N] ] 




t [Soll:Pli 


«in][N][A]] 


-> 


[[Plan n][N][A]] 


1 


[ [Soll:Pli 


Jnn][N][Al[1]J 


-> 


[ [Soli] [N] [A] [1]] 


2 


[ [SollPh 


in n] [N] (A] [2] ] .Remove' 


-> 


[ [Plan n] [N] [A] [2] ] .Remove' 


3 


[[Soll:Plann][N][AJ[3]] 


-» 


[ [Soil] [N] [A] [3]] 



15 



B [[Soll:Plann][N][B]] [ [Plan n] [N] [B] ] 

20 1 [[Soll:Plann][NI[B][1]] -> [ [Soil] [N] [B] [1] ] 

2 [ [Soll:Plan n] [N] [B] [2] ] .Remove' [ [Plan n] [N] [B] [2] ] .Remove* 

3 [[Soll:Plann][N][B][3]] ■» [ [Soil] [N] [B] [3] ] 

wie sie in Fig.2c auch bildlich dargestellt und in der die Endpunkte der Leitung 2 aufgrund des Intention-Attributs 
..Remove" als eliminiert gekennzeichnet ist. In der Kolonne links ist die Uberlagerung, in der Kolonne rechts das dem 
Betreiber angezeigte Ergebnis der Oberlagerung dargestellt. 

In dem anhand von Fig. 2 beschriebenen Beispiel wird eine neue geplante Soll-Konfiguration „Soll:Plan n" durch 

30 Oberlagerung der aktuellen Soll-Kbnfiguration „Soll" mit einer einzigen Plan-Konfiguration „Plan n" erzeugt. Es ist aber 
auch denkbar, eine neue Soll-Konfiguration „Soll:Plan n" mit mehreren Plan-Konfigurationen „Plan 1 ", ..Plan 2", ... " zu 
erzeugen . Auf diese Weise lasst sich das Netzwerk N _s£j3uttweisea fflrsorqlich fur bestimmte Zeitpunkte planen, indem 
die Soll-Konfiguration mit einer ersten Pla tt- Konfiguration uberlaaert wir d und so jeweils eine neue geplante Soll-Konf i- 
guration entsteht, die ihrerseits in weiteren Schritten nach Bedarf mit eiiier weiteren Plan-Konfiguration iiberlagertwird. 

35 Die Abfrage zur Oberlagerung der Soll-Konfiguration „Soll" mit den drei Plan-Konfigurationen „Plan 1", ..Plan 2" und 

„Plan 3" wurde formal (get [ [SoihPlan 1 :Plan 2:Plan 3] 0 [] [ ]] > lauten. Die bei diesen Planungen bzw. Plahungs- 

versuchen verwendeten Plan-Konfigurationen konnen in der Datenbank MIB gespeichert und bei Bedarf abgerufen 
werden, urn im gewunschten Betriebszeitpunkt das Netzwerk N wie beschrieben zu konf igurieren. Denkbar ist auch, 
nicht nur die verwendeten Plan-Konfigurationen, sondern auch die aus den Planungen resultierenden geplanten Soll- 

40 Konfigurationen in der Datenbank MIB fur eine spatere Verwendung bereitzuhalten. 

Wie erwahnt, konnen mit dem beschriebenen Vorgehen zum Oberlagern einer Soll-Konfiguration mit einer Oder 
mehreren Plan-Konfiguration auch Fehlplanungen festgestellt werden.Es sei angenommen, bei der Planung gemass 
Fig. 2b ist statt des Objektes NB2 falschlicherweise das Objekt NB1 als zu loschendes Objekt eingetragen worden. Der 
Objektbaum gemass Fig. 3b gibt diesen Sachverhalt wieder. Wenn nun diese fehlerhafte Plan-Konfiguration „Plan n" in 

45 der beschriebenen Weise auf die Soll-Konfiguration (Fig.3a) „gelegt" wird, resultiert die fehlerhafte Konf iguration „SoN" 
gemass Fig.3c. In dieser Konfiguration stellt man fest, dass die Leitung 3 wie gewunscht bestehen bleibt, indem deren 
Objekte NA3 und NB3 unverandert geblieben sind und richtig referenzieren. Man stellt aber auch fest, dass die Objekte 
NB2 und NA1 auf die Objekte NA2 bzw. NB1 referenzieren, die als nicht mehr vorhanden gekennzeichnet sind. D.h. 
statt wie beabsichtigt nur die Leitung 2 zu eliminieren, wurde durch fehlerhafte Planungsdaten zusatzlich noch die Lei- 

50 tung 1 eliminiert. Beim Oberlagern der Soll-Konfiguration mit der Platt-Konf iguration wird die Fehlplanung vom Betriebs- 
system OS mit einem Plausibilitatstest unverzuglich erkannt und dem Betreiber am Bildschirm angezeigt, der dann 
rechtzeitig vor der Uberf Cihrung der betreffenden Plan-Konfiguration in das Netzwerk N die notigen Korrekturen vorneh- 
men kann. Ferner kann das Betriebssystem OS so ausgelegt werden, dar die Implernentierung von Fehlplanungen in 
das Netzwerk N verhindert wird. 

55 

Patentanspruche 

1. Verfahren zum Planen und Konfigurieren eines aus Netzwerkelementen (NE1, NE2, NEk) bestehenden Kom- 
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munikationsnetzwerkes (N) , dessen Netzwerkelemente (NE1, NE2, NEk) uber eine Schnittstelle (QS) konfigu - 
jierbar sind, dadurch gekennzeichnet, dass eine Datenbank (MIB) vorgesehen ist, in die fur verschiedene 
s Betriebszeitpunkte gjpjg nte Konfigu rationsand erungen enthaltende Plan-Konfigurationen des Netzwerkes (N ) ein- 
nes peichert warden . v mitdenen die betnebsparameter der Netzwerkelemente (NE1, NE2, NEk) entsprecherid 
5 der Planung einstellbar sinff," ds^fufTedeTTan-l^'nf iguratfoh die Netzwerkelemente" (NE1, NE2, .... NEk) als 

Objekte mit den einzustellenden Betriebsparametern in einem Objektbaum erfasst werden, dessen JJateoJoi 
gewunschten Betriebe zeitpunkt aus der Datenbank (MIB) abgerufen und uber die Schnittstelle (QS) dem Kommu- 
nikationsnetzwerk (N) zugefuhrf werden, so'dass'ftfr diesen Betriebszeitpunkt im Kommunikationsnetzwerk (N) 
Iwhe^ll-Konfiguration'eingesfelltwiicl, die der gewunschten Plan-Kontiguration entspricht. 

w 

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass in der Datenbank (MIB) die dem tatsachlichen 
Zustand der Netzwerkelemente (NE) des Netzwerkes (N) entsprechende Soll-Konfiguration (Soli) als Objektbaum 
gespeichert ist, welche Soll-Kbnfiguration (Soli) jeweils nach der Uberfuhrung einer neuen Plan-Konfiguration 
(Plan n) in das Kommunikationsnetzwerk (N) entsprechend aktualisiert wird. 

15 

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass eine fur einen ktinftigen Einsatz geplante Soll-Konfi- 
guration (Soll:Plan n) durch Uberlagerung der aktuellen Soll-Konfiguration (Soil) mit einer oder mehreren Plan- 
Konfigurationen (Plan n) gebildet und das Ergebnis der Uberlagerung sichtbar gemacht wird. 

20 4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass die Adresse der Objekte der zu uberlagernden Kon- 
figurationen (Soli; Plan n) eine Identification enthalt, die darauf hinweist, zu welcher Konfigurationsart (Soli bzw. 
Plan n) das Objekt gehflrt. 

5. Verfahren nach Anspruch 4,' dadurch gekennzeichnet, dass im Distinguished Name der Objektadressierung ein 
25 Relative Distinguished Name mit einem die Konfigurationsart kennzeichnenden Attributwert eingefuhrt wird. 

6. Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, dass die Uberlagerung einer Soll-Konfiguration 
(Soil) mit einer Plan-Konfiguration (Plan n) mit einer Abfrage (get „Soll:Plan n") erfolgt und dabei Clbereinstim- 
mende Objektadressen gesucht wenden, wobei die Suche jeweils in der letzten Objektadresse beginnt und bei feh- 

30 lender Ubereinstimmung auf die vorhergehenden Objektadressen ausgedehnt wird, bis eine Ubereinstimmung 
gefunden wird. 

7. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass jede durch eine Uberla- 
gerung entstandene geplante Soll-Konfiguration (Soll:Plan n) vor der Uberfuhrung in das Kommunikationsnetzwerk 

35 (N) einem Plausibilitatstest unterzogen wird. 

8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass wenn der Plausibilitatstest einen Fehler ergibt, die 
Uberfuhrung der betreffenden Plan-Konfiguration in das Netzwerk (N) verhindert wird und die betroffenen Objekte 
angezeigt werden 

9. Anordnung zur Durchfuhrung des Verfahrens nach Anspruch 1 , dadurch gekennzeichnet, dass eine Datenbank 
(MIB) vorgesehen ist, in der die Daten verschiedener Konfigurationen (SOLI;; PLAN) des Netzwerkes (N) gespei- 
chert sind, dass ein Betriebssystem (OS) zum Ein-und Auslesen der in der Datenbank (MIB) gespeicherten Daten, 
zum Uberlagern einer Soll-Konfiguration mit einer oder mehreren Plan-Konfigurationen sowie zum Uberfuhren der 

45 Daten in das Netzwerk (N) vorgesehen ist, und dass ein Bediente (OP) vorgesehen ist, uber das dem Betriebssy- 
stem (OS) Befehle und Daten zufuhrbar sind. 
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